Aha, I see what you did here. Just let´s clarify so that I can better understand your intentions.

I guess you want to open the library for future patch versions; that´s why you widened the version of the zip dependency. I want to avoid potential issues with breaking changes introduced in minor versions, so it might be good to specify "2.1" instead of "2". This would allow patch updates, but breaking changes according to semantic versioning can be prevented.

Second, the fine-grained control of the zip crate's specific features is interesting but new. The list of default features you set matches the features enabled by the zip crate by default; at least, I can quickly grasp this from the zip documentation. Since the list of features is quite lengthy, I am afraid of the maintenance burden of keeping this in sync with the zip crate. Could you shed some light so I can better understand the benefit of it? I can only assume that it helps speed up the build.

@matzefriedrich

• updated to "2.1" instead
• my concern is to disable some features to reduce the binary size. we may only need some compression algorithms (e.g., deflate) or disable encrypt support in some cases (like embedded devices).

@yujincheng08 If I get this right, to allow consumers of the zip extension crate to control its features, I need to "proxy" the zip crate features. This involves defining corresponding features in the extension crate's cargo. toml to make the respective features of the zip crate configurable.